Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint by WaffleLapkin · Pull Request #148214 · rust-lang/rust

WaffleLapkin · 2025-10-28T15:21:27Z

This is an extension to #147382.

With this PR Result<T, Uninhabited> and ControlFlow<Uninhabited, T> considered as must use iif T must be used.

For such cases the lint will mention that T is wrapped in a Result/ControlFlow with an uninhabited error/break.

The reasoning here is that Result<T, Uninhabited> is equivalent to T in which values can be represented and thus the must-used-ness should also be equivalent.

Fixes #65861

rustbot · 2025-10-28T15:21:32Z

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

fee1-dead

impl LGTM

View changes since this review

jackh726 · 2025-10-29T15:55:21Z

So, the lang team discussed this in the triage meeting today. Overall sentiment was positive that this is probably something we want to do at some point, but there was one concern: people may rely on this today to ensure that people "observe" the state of the Ok variant, since we don't have a nice way today to mark that as must_use without making a newtype. So, to give a concrete example:

fn foo<E>() -> Result<u32, E>; // people may expect that you will check the value of the `u32`

I suggested that we could actually just get some real word data on this using crater. My thought was, we could do an experiment were we error on any function that (after monomorphization) returns Result<T, !> for any T that is not must_use (and maybe separately for any T that is must_use to get a counter set).

I do expect that this will result in a non-small amount of cases, but I think it might be a small enough set that we could browse through and get a sense of if this type of thing is relied upon.

Would you be interested in doing that experiment @WaffleLapkin? If not, I'm happy to help out and try that myself (or I can help if you do want to be involved).

WaffleLapkin · 2025-10-29T16:20:12Z

@jackh726 I'd be happy to do the experiment. I might reach out for some help though ^^'

jackh726 · 2025-10-29T17:09:18Z

Sounds good! Let me know, happy to help if you run into issues.

jackh726 · 2025-12-02T17:38:13Z

Copying this from #148577 (comment)

So, what's very clear is that this pattern comes in a lot of places. Definitely more than I would have expected coming into this. With this being said, I've gone through and opened a few crater results to see if I could spot any examples of @joshtriplett's concern, which was basically like "People may be relying on that Result<T, E> is always must_use to ensure that T is also must_use". The idea (from what I can try to summarize) was that perhaps there is some state in T that would be need to be observed in order to avoid subtle bugs.

So, going into this, I'm looking for types where the Ok variant seems to encode some "meta-state" that must be observed for correctness. There are obviously way too many examples for me to be exhaustive here. And, I have yet to find a situation that follows the pattern to be worried about.

That being said, given that this comes up so much, I think this decision is likely not as "light" as the lang team originally expected. Though, it's completely backwards- and forwards- compatible to make this change and undo later. Here a couple of examples of code I saw, though far from exhaustive.

`no_std_net`

pub trait ToSocketAddrs {
    type Iter: Iterator<Item = SocketAddr>;
    fn to_socket_addrs(&self) -> Result<Self::Iter, ToSocketAddrError>;
}
pub enum ToSocketAddrError {}

`zino_http`

let session_id = self
    .get_header("x-session-id")
    .or_else(|| self.get_header("session_id"))
    .and_then(|s| s.parse().ok()); // <- this parse relies `<String as FromStr>` which has `Err = Infallible`
ctx.set_session_id(session_id);

`zerocopy`

fn checked_shr(self, rhs: Self) -> Option<Self> { self.checked_shr(rhs.try_into().unwrap_or(u32::MAX)) }
                                                                                                     //^^^^^^^^ returns `Result<u32, Infallible>`

clap things

(this comes up a bunch, so just putting an example error, as I haven't dug into the actual pattern; it's also not super clear to me what the actual lint would be)

error: this type will no longer be must used: Result<std::string::String, Infallible>
  --> src/main.rs:72:9
   |
72 | /         /// A path to a project directory or a `Cargo.toml` file. If this is
73 | |         /// not provided, the current directory will be searched.
74 | |         #[clap(verbatim_doc_comment)]
75 | |         path: Option<String>,

rust-bors · 2026-05-09T09:08:07Z

📋 This PR cannot be approved because it currently has the following label: S-waiting-on-fcp.

WaffleLapkin · 2026-05-09T09:14:00Z

@bors r=fee1-dead

rust-bors · 2026-05-09T09:14:04Z

📌 Commit 4c4416b has been approved by fee1-dead

It is now in the queue for this repository.

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to #147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes #65861

jhpratt · 2026-05-09T13:52:47Z

stalled

@bors yield

@bors try dist-x86_64-apple

rust-bors · 2026-05-09T13:52:51Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/25598699843

The next pull request likely to be tested is #156361.

rust-bors · 2026-05-09T13:52:51Z

Unknown argument "dist-x86_64-apple". Did you mean to use @bors jobs=<jobs>|parent=<parent>? Run @bors help to see available commands.

jhpratt · 2026-05-09T13:53:05Z

@bors try jobs=dist-x86_64-apple

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint try-job: dist-x86_64-apple

rust-bors · 2026-05-09T16:31:26Z

☀️ Try build successful (CI)
Build commit: a975fb6 (a975fb6ac43f7ec2e8f1b0a75ab8006da5c54121, parent: 0490dd938541ad996c5ad1ec6e274012afe3e1d4)

…, r=fee1-dead Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang#65861

Rollup of 5 pull requests Successful merges: - #148214 (Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint) - #149362 (Add Command::get_resolved_envs) - #155188 (Add regression test for issue 144329) - #155515 (error on empty `export_name`) - #155817 (validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters)

…, r=fee1-dead Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang#65861

…uwer Rollup of 10 pull requests Successful merges: - #148214 (Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint) - #149362 (Add Command::get_resolved_envs) - #155705 (Add `str::word_to_titlecase()` to `alloc`) - #155970 (Add mention of sendfile(2) and splice(2) to fs::copy() documentation.) - #156006 (Update a bunch of bootstrap dependencies to remove windows-target) - #155188 (Add regression test for issue 144329) - #155515 (error on empty `export_name`) - #155817 (validate `#[link_name = "..."]` & `#[link(name = "...")]` parameters) - #156107 (remove turbofish notation + use None / Some instead of Option:: (in match documentation)) - #156133 (mark some panicking methods around Duration as track_caller)

rust-bors · 2026-05-10T02:00:59Z

☀️ Test successful - CI
Approved by: fee1-dead
Duration: 3h 11m 9s
Pushing ce89c89 to main...

github-actions · 2026-05-10T02:03:45Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 82bee96 (parent) -> ce89c89 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard ce89c898570852a1bb441d77570596e50bf362c2 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-msvc-ext3: 1h 21m -> 1h 51m (+37.6%)
dist-x86_64-mingw: 1h 59m -> 2h 35m (+30.0%)
test-various: 1h 30m -> 1h 53m (+25.6%)
dist-x86_64-llvm-mingw: 1h 58m -> 1h 28m (-24.8%)
optional-x86_64-gnu-parallel-frontend: 2h 23m -> 1h 49m (-23.6%)
dist-i686-mingw: 2h 9m -> 2h 38m (+22.7%)
armhf-gnu: 1h 25m -> 1h 7m (-20.6%)
dist-x86_64-msvc-alt: 2h 42m -> 2h 11m (-19.0%)
pr-check-1: 25m -> 29m 13s (+16.9%)
aarch64-apple: 2h 31m -> 2h 49m (+12.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-05-10T02:49:59Z

Finished benchmarking commit (ce89c89): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.5%	[3.5%, 3.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-5.0%	[-9.9%, -2.3%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-9.9%, 3.5%]	4

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 497.725s -> 498.161s (0.09%)
Artifact size: 397.13 MiB -> 397.12 MiB (-0.00%)

rustbot assigned fee1-dead Oct 28, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 28, 2025

rustbot mentioned this pull request Oct 28, 2025

Tracking issue for release notes of #148214: Consider Result<T, Uninhabited> and ControlFlow<Uninhabited, T> to be equivalent to T for must use lint #148215

Open

fee1-dead approved these changes Oct 28, 2025

View reviewed changes

fee1-dead removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 28, 2025

WaffleLapkin mentioned this pull request Nov 6, 2025

[DO NOT MERGE] crater proposed changes in unused must use lint #148577

Closed

WaffleLapkin added the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Nov 13, 2025

WaffleLapkin force-pushed the never-worn-never-type branch from 17a892b to 69a5724 Compare December 2, 2025 10:14

This comment has been minimized.

Sign in to view

WaffleLapkin removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Dec 7, 2025

WaffleLapkin removed the S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. label May 9, 2026

rust-bors Bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label May 9, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request May 9, 2026

Auto merge of #148214 - WaffleLapkin:never-worn-never-type, r=<try>

a975fb6

Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint try-job: dist-x86_64-apple

matthiaskrgr mentioned this pull request May 9, 2026

Rollup of 5 pull requests #156369

Closed

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 11 pull requests #156371

Closed

JonathanBrouwer mentioned this pull request May 9, 2026

Rollup of 10 pull requests #156374

Closed

This comment has been minimized.

Sign in to view

rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 10, 2026

rust-bors Bot merged commit ce89c89 into rust-lang:main May 10, 2026
13 checks passed

rustbot added this to the 1.97.0 milestone May 10, 2026

Uh oh!

Conversation

WaffleLapkin commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 28, 2025

Uh oh!

fee1-dead left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jackh726 commented Oct 29, 2025

Uh oh!

WaffleLapkin commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jackh726 commented Oct 29, 2025

Uh oh!

This comment has been minimized.

jackh726 commented Dec 2, 2025

no_std_net

zino_http

zerocopy

clap things

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

WaffleLapkin commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

jhpratt commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

rust-bors Bot commented May 9, 2026

Uh oh!

jhpratt commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 9, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented May 10, 2026

Uh oh!

Uh oh!

github-actions Bot commented May 10, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented May 10, 2026

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

WaffleLapkin commented Oct 28, 2025 •

edited

Loading

fee1-dead left a comment •

edited by rustbot

Loading

WaffleLapkin commented Oct 29, 2025 •

edited

Loading

`no_std_net`

`zino_http`

`zerocopy`